In a distributed computing system components constituting an application are physically located on different computers connected by a network. A middleware framework or architecture is used to establish a communication, access a remote application and exchange data without having knowledge of its low level technical operating details. Thus, the middleware framework acts as an intermediary to enable access to a remote application without having knowledge of the network protocol.
A procedure is a section of code that can be called from other parts of the same, albeit a larger, program. The concept of a remote procedure call (RPC) occurs when a procedure is invoked by another program, often running elsewhere on a network. Traditional RPC denotes a coupled form of distributed computing. In other words, procedure calls are innately synchronous, based on a request-reply protocol wherein the calling program blocks or waits until the procedure is complete. This applies to both local and remote calls, but what distinguishes one case from the other is the issue of availability. Given an operational network the “presence” of the procedure is assumed by the caller at the time of the call, which is generally safe if the procedure is local. However, the outcome of a call made to an unavailable remote procedure is circumstantial. A performance problem will only yield a slow response which delays the caller; however, a system or network failure will produce an error condition resulting in the loss of the call. Failed procedure calls need to be resubmitted as they are not subject to transactional control.
One type of middleware is message-oriented middleware (MOM) that enables communication between software applications much like e-mail systems do for users. Messages may be passed in either a point-to-point or a publish-subscribe fashion. In the former case, a message produced by an application is consumed by exactly one other application, while for the latter, a message may be consumed by none, one or multiple applications. It is somewhat common, albeit dependent upon the implementation of a specific MOM provider (e.g., WebSphere MQ or Active MQ) that messaging occurs in a store-and-forward manner based on the premise of message queuing. The queuing is a device that holds and distributes messages. Messages are retained in the queue until one or more recipients have collected them. The queue acts as a physical intermediary, which effectively decouples the sender from the recipient of the message. Message queues help to ensure that messages are not lost, even if the receivers are momentarily unavailable (e.g., due to network disconnection).
Message queuing systems may connect senders and receivers in several ways. In a peer-to-peer topology a single sender is connected to a single receiver via a single queue. Alternatively, in a hub-and-spoke more complex interactions are provided such as one-to-many or many-to-many wherein the message is distributed to all receivers who have previously indicated interest in the topic by registering as subscribers with a common broker. Typically, message queuing systems enable the interconnection of multiple physical queues into one logical queue, with one queue manager on the sender side and another on the receiver side, providing improved decoupling between sender and receiver.
Another type of middleware is referred to as object-oriented middleware (OOM) which is based on object oriented programming (OOP) and manipulation at the distributed network level. The concept of OOP has emerged as an alternative to the conventional modular programming styles based on procedure or function calls. The field of OOP is grounded in the reuse of successful design techniques. A coherent and flexible enterprise system is, by and large, associated with the adoption of design patterns, i.e., a collection of documented approaches to applied object-oriented principles discovered through practice. Distributed objects are supported by an Object Request Broker (ORB) which manages the communication and data exchange with remote objects across a network. Some examples of more commonly employed ORB implementations include CORBA (the Common Object Request Broker Architecture) (universally applicable to multiple platforms and programming languages), Microsoft's Distributed Common Object Model (DCOM) (restricted to Microsoft platforms) and Java's Remote Method Invocation (RMI) (restricted to Java platforms). CORBA, DCOM and RMI employ object servers which conduct the instantiation process for their hosted objects. Invocation occurs in response to requests from client applications typically residing elsewhere on the network. Accordingly, conventional ORBs support instantiation and invocation at the same host.
It is desirable to develop an object oriented middleware framework with substantially greater flexibility in which invocation of a Command occurs locally but remotely from instantiation.